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prnMHttV OF TYT T WVE ^ TI0N 

This invention is directed to certain hardware and 
Boftware improvements in workstations vhich utilize virtual 
addressing in multi-user operating systems vith write back 
caches, including operating systems which allow each user to 
have multiple active processes. In this connection, for 
convenience the invention will be described with reference 
to a particular multi-user, multiple active processes 
operating system, namely the Unix operating system. 
However, the invention is not limited to use in connection 
with the Unix operating system, nor are the claims to be 
interpreted as covering an invention which may be used only 
with the Unix operating system. 

in a Unix based workstation, system performance may be 
improved significantly by including a virtual address write 
back cache as one of the system elements. The present 
invention describes an efficient scheme for supporting data 
protection and the reassignment of virtual addresses within 
such a system. The invention features support for multiple 
active processes, each with its own virtual address space, 
and an operating system shared by those processes in a 
manner which is invisible to user programs. 

Cache "Flush" logic is used to remove selected blocks 
from the virtual cache when virtual addresses are to be 
reassigned. If a range of addresses (a virtual page 
address, for example) is to be reassigned, then all 
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instances of addresses from vithin this range oust be 
removed, or -flushed", from the cache before the new address 
assignment can, be made. A cache block is "flushed" by 
invalidating the valid bit in its tags and writing the block 
back to memory, if the block has been modified. The "Flush" 
logic includes logic to identify "Flush" commands vithin 
"Control Space"; logic to match particular virtual address 
fields, within a Flush command, to corresponding virtual 
address fields either within the cache's block address sp*ce 
or its tag virtual address field; and (optional) logic to 
flush multiple cache block addresses as a result of a single 
"Flush" command issued by the CPU (or DVMA device, if 
allowed) . It also includes logic to invalidate the cache 
valid tag on matching cache blocks and logic to enable 
modified matching blocks to be written back to memory. 

The present invention includes both hardware and 
specific "Flush" commands inserted within the operating 
system kernel. 

pPTFF DESr^TPTION OF THE DRAWINGS 

Figure 1 is a block diagram showing the main components 
of a workstation utilizing virtual addresses with write back 
cache . 

Figure 2a is a schematic diagram of cache "hit" logic 

25. 
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Figure 2b is a scheaatic diagraa of a circuit for 
detecting a cache protection violation. 

Figure 2c is a schematic diagram of a circuit fcr 
detecting a MKU protection violation. 

Figure 3 is a detailed block diagraa showing the 
address path utilized by the virtual address cache of the 
present invention. 

Figure 4 (4(a), 4(b)) is a flow diagram of a state 
machine implementation for certain controls related to the 
addressing of a virtual address write back cache. 

Figure 5 is a detailed block diagram showing the data 
path utilized by the virtual address path of the present 
invention. 

Figure 6 (6a, 6b, 6c and 6d) is a flow diagram of a state 
machine implementation for certain controls related to data 

transfers to and from a virtual address write back cache 
(states (a) - (o) ) . 

Figure 7 is a flow diagraa of a state machine for 
implementation for controlling Write Back bus cycles to 
memory. 

• Figure 8 is a timing diagram for best case timing f o: 
& cache vrite miss. 
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Figure 9 is a timing diagram for best case timing for 
a cache read miss.- 

Figure 10a is a timing diagram of the memory bus cycle 
for performing a block read cycle. 

Figure 10b is a timing diagram of the memory bus cycle 
for performing a write back cycle. 

Figure 11 is a schematic diagram showing the cache 
flush implementation of the present invention. 

Figure 12 is a schematic diagram showing the logic for 
detection of context Flush Match, Segment Flush Match and 
Page Flush Hatch. 

Figure 13 (13a - 13e) is a flow diagram of a state 
machine implementation of a cache flush initiated by the 
issuance of a flush command. 

Figure 14 is a timing diagram for a cache flush. 

DESCRIPTION OF THE INVENTION 

Figure 1 shows the functional blocks in a typical 
workstation using virtual addresses in which the present 
invention is implemented. 

Specifically, such a workstation includes a 
microprocessor or central processing unit (CPU) 11, cache 
data array 19, cache tag array 23, cache hit comparator 25, 
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memory i»it (HKU) 27, «ain memory 31. write back 

buffer 39 and workstation control logic 40. Such 
workstations may, optionally, also include context ID 
register 32, cache flush logic 33, direct virtual memory 

access (DVKA) logic 35, and multiplexor 37. 

in the present invention, various changes are made to 

cache flush logic 33, cache hit comparator 25 and 

vorkstation control logic 40 vhich improve the performance 

of a virtual address write back cache. 
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CPU 11 issues bus cycles to address instructions and 
data in memory (following address translation) and possibly 
other system devices. The CPU address itself is a virtual 
address of (A) bits in size which uniquely identifies bytes 
of instructions or data within a virtual context. The bus 
cycle may be characterized by one or more control fields to 
uniquely identify the bus cycle. In particular, a 
Head/write indicator is required, as well as a "Type" field. 
This field identifies the memory instruction and data 
address space as well as the access priority (i.e., 
-Supervisor" or -u..r- access priority) for the bus cycle. 
A CPU which may be. utilized in a workstation having virtual 
addressing and capable of supporting a multiuser operating 
cystem is a MC68 020. 
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Another necessary element in a virtual address 
workstation with vrite back cache shown in Figure 1 is 
virtual address cache data array 19, vhich is organized as 
an array of 2* 'blocks of data, each of which contains 2* 
bytes. The 2« bytes within each block are uniquely 
identified with the low order H address bits. Each of the 
2* blocks is uniquely addressed as an array element by the 
next lowest K address bits. As a virtual address cache, the 
(H+M) bits addressing bytes within the cache are from the 
virtual address space of (A + C) bits. (The (C) bits are 
context bits from optional context ID register 32 described 
below.) The (N+K) bits include, in general, the (P) 
untranslated page bits plus added virtual bits from the 
(A+C-P) bits defining the virtual page address. 

Virtual address cache data array 19 described herein is 
a "direct mapped" cache, or "one way set associative" cache. 
While this cache organization is used to illustrate the 
invention, it is not meant to restrict the scope of the 
invention which may also be used in connection with multi- 
way set associative caches. 

Another required element shown in Figure 1 is virtual 
address cache tag array 23 which has one tag array element 
for each block of data in cache data array 19. The tag 
array thus contains 2* elements, each of which has a Valid 
bit (V) , a Modified bit (M) , two protection bits (P) 
consisting of a Supervisor Protect bit (Supvsr Prot) and a 
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write Allowed bit, and a -virtual address field (VA, and 
optionally CX) as shown in Figure 3. The contents of the 
virtual address field, together with low order address bits 
used to address the cache tag and data arrays, uniquely 
identify the cache block within the total virtual address 
space of (A+C) bits. That is, the tag virtual address field 
must contain ((A+C) - (M+N) ) virtual address bits. 

Cache "Hit" logic 25 compares virtual access addresses 
with the contents of the virtual address cache tag address 
field. Within the access address, the lowest order K bits 
address bytes within a block; the next lowest N bits address 
a block within the cache; and the remaining ((A+C) - (M+N) ) 
bits compare with the tag virtual address field, as part of 
the cache "hit" logic. 

The cache "hit" logic must identify, for systems with a 
shared operating system, accesses to user instructions and 
data, and to supervisor instructions and data. A "hit" 
definition which satisfies these requirements is illustrated 
in Figure 2a which comprises comparators 20, AND gate 22, OR 
gate 24 and AND gate 26. 

MMU 27, which translates addresses within the virtual 
space into a physical address, is another required element. 
KWU 27 Is organized on the basis of pages of size (2?) 
bytes, which in turn are grouped as segments of size (2 s ) 
pages. Addressing within a page requires (P) bits. These 
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(P) b it. are physic^ address *°*> iT ' "° 

Relation. The role of »» « i- ~ *" VirtU01 

P age address bit. «A + C-P> or (A-P» into physical page 
addresses of (KH) bits. The composite physical address is 
then (KM) P>9« »=oress bits vlth (» bit. per page. 

MHO 27 1. also the locus tor protection checking, i.e., 
comparing the access bus cycle priority vlth the protection 
..signed to the page. To illustrate this point, there are 
* v0 types of protection that may be assigned to a page 
namely, a su P ervi.or/t>.er access designator and a write 
Protect/write Allowed designator. Although the subject 
invention 1. not United to such types of protection, given 
this page protection, a -Protection Violation" can result if 
either a -User" priority bus cycle acces.e. a page with 

~ * + m HUrite" bus cycle accesses 
"Supervisor" protection! or if a Write 

a page vith a "Write Protect" designation. 

The application of KMU protection checking through the 
M 1. shown in Figure =c which compri.e. inverter ... *»» 
gate. 20a and 30b, OR gate 34 and AMD gate ... In addition, 
vlth a virtual address write back cache, the concept of 
protection checking can be extended to cache only CPU cycles 
Which do not access the KMU. Such cache only protection 
log ic is .hovn in Figure 2b comprising Inverter 42, AND 
gates 44e and 44b. OK gate 46 and AND gate 4B. 




9 - 

Also shown in Figure 1 is main memory 31 vhich is 
addressable within' the physical address cpace; control of 
main memory access is through workstation control logic 40. 

Write back buffer 39 is a register containing one block 
of cache data loaded from cache data array 19. Write back 
buffer 39 is loaded whenever an existing cache block is to 
be displaced. This may be caused by a need to update the 
cache block with new contents , or because the block must be 
flushed. In either case, in a write back cache, the state 
of the cache tags for the existing cache block determine 
whether this block must be written back to memory. If the 
tags indicate that the block is valid and modified, as 
defined below, then, the block contents must be written back 
to memory 31 when the cache block is displaced. Write back 
buffer 39 temporarily holds such data before it is written 
to memory. 

Workstation control logic 40 controls the overall 
operation of the workstation elements shown in Figure 1. In 
the preferred embodiment, control logic 40 is implemented as 
several state machines which are shown in Figures 4, 6, 7 
and 13 as will be described more fully below in conjunction 
with the description of cache flush logic 33, portions of 
vhich aje also, in the preferred embodiment, integrated into 
the workstation control logic. 

Descriptio n of Optional Elements of Workstation 
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Context ZD register 32 is an optional external address 
register vhich contains further virtual address bite to 
identify a virtual context or process. This register, 
containing C bits, identifies a total of <2**C> active user 
processes; the total virtual address space is of size 

to important component in this virtual address space of 
2 . M * + C) bits is the address space occupied by the operating 
system. The operating system is common to all user 
processes, and so it is assigned to a common address space 
across all active user processes. That is, the (C, context 
bits have no meaning in qualifying the addresses of pages 
within the operating system. Rather, the operating system 
is assumed to lie within a common, exclusive region at the 
top of the (2«X) bytes of virtual address space for each 
.ctive context. Ho user pages may lie within this region. 
S . the operating system page addresses for two distinct user 
processes are identical, while the user pages for the two 
processes are distinct. All pages within the operating 
system are marked as having -Supervisor" protection. 

Cache flush logic 33 is also an optional element in a 

-Flush Iodic 33 is included, and 
workstation. However, cache flusn logic 

Bodified as described in detail below in order to improve 
t*. performance of a virtual address, write b.=H cache 
.ystem. Briefly however, cache flush logic 33 operates as 
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follows. If e range of address (a virtual page address, 
for example) is to be reassigned, then all instances of 
addresses fro. within this range must be removed, or 
-flushed-, from the cache before the new address assignment 
can be made. A cache block is "flushed" by invalidating the 
valid bit in its tags and writing the block back to memory, 
if the block has been modified. 

in addition to CPU 11 as a source of bus cycles, the 
workstation may include one or more external Input/output 
(I/O) devices such as DVMA logic 35. These external I/O 
devices are capable of issuing bus cycles which parallel the 
CPU in accessing one or more "Types" of virtual address 
spaces. The virtual address from either the CPU 11 or DVKA 
logic 35, together with the address in context ID register 
32, is referred to as the access address. 

Another optional element is data bus buffer 37, which 
in the preferred embodiment is implemented as two buffers to 
control data flow between a 32 bit bus and a 64 bit bus. 
Such buffers are needed when the CPU data bus is 32 bits and 
the cache data array data bus is 64 bits. 

r ._„, r ^ n ^ Unique tn thn Tn^nl-o* Workstation 

in the present invention, the definition of a cache 
-Hit- is modified "to take into account the use of a shared 
operating system across multiple active user contexts, and 
the access priority and page protection. By so doing, an 
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efficient indication of a protection violation within the 
vrlte back virtual address cache can be achieved. 
Specifically, to implement the protection definition 
presented above, the followina cache "Hit" definition is 
utilized. • 

A cache "Hit" has three requirements: 

1) The cache block must be marked as having valid 
contents . 

2) ignoring the (C) context bits, the access virtual 
address bits (A-(H-fM)) must match the corresponding tag 
virtual address field bits (A-(N+M)), at the cache 
block addressed by the (N) bus access bits. 

3) Either the (C) bits of the access context ID must 
match the corresponding (C) context bits in the cache 
tag virtual address field, or the cache tag Supervisor 
protection bit must be set active. 

' This definition of a cache "Hit" enables cache 

protection checking to be applied directly to the virtual 
address cache, rather than defined through an MMU check 
during cache miss handling. K "Protection Violation" on a 
cache "Hit" results: 

1)' if the access bus cycle has "User" priority and the 
cache block has "Supervisor" protection; or 



2) if the access is" a Write bus cycle and the cache 
block has Write Protection. 
An implementation of cache hit detector 25 according -to the present 
Invention is shown in Figure 2a described hereinabove. 

The present invention utilizes a set of "Flush" 
commands in the Control Space to efficiently implement 
virtual address reassignment in a virtual address vrite back 
cache. 

in general, Flush commands are bus cycles in Control 
Space which specify, for each unique type of Flush command, 
one or more virtual address fields to be compared vith 
corresponding virtual address fields, in the- virtual address 
cache tags. -Matching" address fields cause the hardware to 
-flush" the cache block. To ".flush" the cache block maans 
that: 

1) A matching cache block that is marked as both 
"Valid" and "Modified" is written back to memory. This 
requires a cache block "write back" bus cycle to the main 
aemory. A "write back" bus cycle writes the contents of an 
entire cache block into main memory at the appropriate 
physical address. As a part of this cycle, the virtual 
address. identifying the cache block is translated through 
the MOT* into a physical memory address. During this 
translation, protection checking for the cache block is 
inhibited. The address translation through the MKU io 
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completed prior to returning control to the processor at the 
conclusion of the flush command. 

2) Any matching cache block that is "Valid", whether 
"Modified" or not, is marked as invalid. 

As described, the -write back", bus cycle requires the 
translation of the cache block virtual address into a 
physical address. The concept of the flush command and 
"write back" bus cycle can also be extended to virtual 
address caches which contain both virtual address and 
physical address tag fields. If a physical address tag 
field is present, no translation is required at the time the 
"write back" bus cycle to main memory is performed. 
However, the present invention is directed to the use of 
virtual address tags to support a virtual address write back 
cache . 

The flush command as described above applies to a 
single cache block. The application of the flush command 
can also be extended so that a single flush command 
activates hardware which checks multiple cache blocks, 
flushing those blocks which match the address fields of the 
flush command. It is only required that the address 
translation of the last cache block flushed be concluded 
prior to returning control to the processor at the 
conclusion of the command. 
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Three specific flush commands are defined below. While 
other similar commands may be defined, these three are 
particularly useful in effectively restricting the scope of 
a "Flush- command to a minimal address range. These -Flush" 
commands are also effective in implementing a multiple 
context, shared operating system address space. 

1. Context Match Flush Command 

The context Match Flush command flushes from the cache 
all cache blocks within a specified context which are from 
User protected pages. It specifies a context identifier of 
(C) bits. The match criteria is to require first, that the 
cache tags identify the block as having User protection; and 
second, that the (C) bit field of the Flush command match 
the corresponding (C) bit Context identification field of 
the tags. 

The Context Match Flush command is used to ensure cache 
addressing consistency whenever a new active context 
replaces an old context in the KHU. The Context Match Flush 
must be performed before the old context references are 
removed from the MMU, since the MMU is required to translate 
the cache blocks' virtual addresses. 

2. -Page Match Flush Command 

The Page Match Flush command flushes from the cache all 
cache blocks within a specified page, regardless of the page 
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protection. It opacifies a page address of (A+C-F) bits. 
The match criteria is to require that first, the (A-P) bit 
field of the Flush command, vhich identifies a virtual page 
address vithin a Context, match the corresponding (A-P) bits 
to identify the virtual page address of a given cache block. 
These (A-P) bits may be in the cache tag virtual address 
field or in a combination of both the cache access address 
and the cache tag virtual address field, depending on the 
page size and the size of the cache. 

The second match criteria is to require that one of the 
following two conditions is met: i) the cache block's 
Supervisor access protection tag is active, or ii) the 
context ID register of (C) bits match the cache block's 
corresponding Context ID tag field of (C) bits. 

The Page Match Flush command is used during page 
management to purge all references to a virtual page - with 
either Supervisor or User protection - from the cache. It 
must be performed before the MMU is updated to remove the 
page, since the MMU is required to translate the cache 
blocks' virtual addresses. 

3. segment Match Flush Command 

The Segment Match Flush command flushes from the cache 
all cache blocks within a specified segment, regardless of 
the page protection. It specifies a segment address of 
«A + C)-(M» bits, since the segment aire is (2**S) pages. 
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The match criteria is to require that first, the (A-(P+S)> 
bit field of the Flush command, which identifies a segment 
vithin a Context, match the corresponding (A-(P+S)) bite 
identifying a segment for a given cache block. These (A- 
<P+S)) bits may be in the ctche tag virtual address field or 
in a combination of both the cache access address and the 
cache tag virtual address field, depending on the segment 
size, the page size, and the size of the cache. 

The second match criteria is to require that one of the 
following two conditions is met: i) the cache block's 
Supervisor access protection tag is active; or ii) the 
context ID register of (C) bits match the cache block's 
corresponding Context ID tag field of (C) bits. 

The Segment Match Flush command is used during page 
management to purge all references to a virtual segment - 
with either Supervisor or User protection - from the cache. 
It may be required, depending on the structure of the KKU, 
whenever the pages of an entire virtual segment must be 
reassigned to a new virtual segment. It must be performed 
before the KMU is updated to remove the segment mapping, 
since the MMU is required to translate the cache blocks' 
virtual addresses. 1 

Flush Command Usage 

The three "Flush" commands defined above, together with 
the respective "match" criteria, are executed only by toe 
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operating system vithin the Unix kernel. The placement of 
flush commands vithin the kernel is described within 
Appendix A. By proper placement of "Flush" commands within 
the kernel, virtual address reassignment for a Unix system 
may be implemented to support a virtual address write back 
cache. 

The set of flush commands defined above, when used in 
the Unix kernel as shown in Appendix A, implement a 
mechanism to support virtual address reassignment, as 
required by a virtual address cache, for a Unix system with 
multiple active contexts and an operating system shared 
across those contexts for workstations having either write 
through or write back caches. 

The flush commands, when used in the Unix kernel as 
shown in Appendix A, support a virtual address write back 
cache within a Unix system so that the use of such a cache 
is transparent to user application programs. No changes are 
required to user programs to take advantage of the memory 
speed improvements inherent in a virtual address write back 
cache. 

Additionally, the flush commands, when used in a Unix 
kernel as shown in Appendix A, support a virtual address 
write back cache implementation which contains only a 
virtual address tag field for block identification, not a 
physical address tag field. Avoiding the addition of a 
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physical address tag field minimizes the number of cache 
tags required for the virtual address write back cache. A 
vrite back cache requires that at some point, any cache 
block which has been modified must be written back into main 
memory. This -write back" operation may take place either 
when the cache block is replaced by new block contents (the 
normal block replacement on a cache "miss") , or when the 
cache block is flushed prior to reassigning a range of 
virtual addresses containing this cache block. 

If the cache tags contain no physical address field, 
then the virtual address tags must be translated into a 
physical address before the cache block may be written into 
memory. In the case of cache flushes, this implies that all 
address translations of cache block virtual address fields 
which result from a flush match must be completed prior to 
the operating system's reassignment of the virtual address 
range within the KKU. Two features of the invention are in 
part responsible for ensuring that this requirement is met: 

1) first, that the flush command requires the 
completion of the cache block virtual address translation 
before control is returned to the processor; 

2) and second, that the flush commands are structured 
in the kernel, as shown in Appendix A, at strategic 
locations which guarantee the flushing of all modified cache 



blocks prior to the reassignment of the virtual address 
range. 

The set of three flush commands defined above, together 
with their respective "match" criteria, constitute an 
efficient virtual address reassignment mechanism vhen placed 
in the Unix kernel as shown in Appendix A. The mechanism is 
efficient in that it optimizes flush performance for the 
virtual address write back cache for the three cases of 
virtual address reassignment required by the operating 
system: 

1) whenever an existing active context is being 
replaced by a new context; 

2) whenever MKU limitations require the reassignment of 
a currently mapped segment to a new segment; and 

3) whenever a physical page in memory is to be 
reassigned to a new virtual address. 

The three flush commands are defined, together with the 
flush match criteria, to specifically cover each of these 
cases. Flush commands are issued by the kernel by starting 
at a base block address, and then incrementing block 
addresses so as to check every block within a fixed address 
range. TTbe flush commands as defined are efficient in 
address reassignment for two primary reasons: 



1) The flush match criteria restrict the number of 
blocks flushed to be only those blocks which require 
flushing within the flush address range. Other extraneous 
addresses, outside the flush range, are checked but are not 
flushed. 

2) For each of the three cases requiring address 
flushing, the defined flush commands allow the cache to be 
checked with a single pass through the appropriate cache 
block address range. For example, to flush a segment, every 
page within the segment must be flushed. If a segment flush 
were not implemented, then multiple passes of page flush- 
commands with varying page addresses might be required to 
complete the segment flush. 

The preferred embodiment of the virtual address cache 
for the address path is shown in Figure 3 and for the data 
path is shown in Figure 5. Flush control logic in the 
preferred embodiment is implemented as showri in Figures 11, 
12, the state machine of Figure 13 and timing diagram of 
Figure 14, A best case timing diagram for writes is shown 
in Figure 8 and for reads is shown in Figure 9. 

In addition to -components previously discussed with 
reference to Figure 1, Figure 3 includes virtual address 
register (VAR) 5^ which stores the current virtual address. 
The elements of the invention appear in Figure 3 are cache 
flush logic 33, the Protection bits (F) in the cache tag 



- 22 



array 23, and the flush match logic 2k uhich is part of cache hit 
detect log 25. 

Also shown in Figure 5 is data register 61 which stores 
data to be written to or which has been read from memory 31 
or cache data array 19. 

In Figures 2, 3, 5, 11 and 12, to avoid unnecessarily 
cluttering the Figures, not all control lines are shown. 
However, the control lines necessary for proper operation of 
the invention can be ascertained from the flow chart of the 
state machines shown in Figures 4, 6, 7 and 13, and timing 
diagrams shown in Figures 8-10 and 14. 

In the flow charts, the following abbreviations are 
utilized: 



KtTA 


- multiplexor 45 


Sel 


- select 


VX 


- virtual address 


RA 


.- real address 


0E 


- output enable 


Ack 


- acknowledge 


Cache Hit? 


- Did cache "hit" logic 25 




detect a cache hit? (Fig 2a) 
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Cache Protect Violation ? 



Did control logic 4 0 detect a 



detect a cache protect violation? 
(Fig 2b) 



Memory Busy? - Has Memory Busy been asserted? 
MKU Protect Viol? - Did control logic 40 detect a 



KtfU protect violation? 
(Fig 2c) 

RAR - real address register 51 
CLK - clock 
Adr - address 



Mem Adr Strobe - memory 31 address strobe 



VAR - virtual address register 5<+ 



Mem Adr Ack? - Has a memory address acknowledge 



been asserted by memory 31? 



Mem Data Strobe 0? - Has memory data strobe 0 been 



Mem Data Ack 0? - Has memory data acknowledge 0 been 



asserted? 



asserted? 



# 



He* Data Strobe 1? - Has memory data strobe 1 been 

asserted? 

Hem Data Ack 1? - Has memory data acknowledge 1 been 

asserted? 

Clk Write Back Buffer - clock write back buffer 39 
CPU Read Cycle? - Is CPU 11 in a read cycle 
Clk Data Reg - clock data register 61 
Valid and Modified Write - Has control logic 40 detected , 

Valid bit(V) and Modified bit(M) 

Back Data? 

, ^_ . _ _ eDn t r ol logic 40 asserted 

Start Write Back Cycle? - Has controx j. g 

Start Write Back Cycle 

Similar abbreviations are used in the timing diagrams 
of Figures 8-10 and 14 • 

The. address state nachine shown in Figures 4s and 4 b 
defines certain of the controls related to the address 
handling portion of cache ». The cache tag. » are vritten 
as valid during state (v, , following a successful transfer 
of all bloc* data fro- *>er,ory 31. The invention is 
integrated through, the inclusion of the cache Protection 
Violation test following state (c) . If a Protection 
Violation is found on a cache Hit. then the CPU bus cycle is 
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terminated Mediately with a Bus Error response to the CPU. 

The KKU Protection Violation on the translated address is 

performed later, following state (g) . 

The data state machine shown in Figures 6a - 6d define 
certain control, related to the data transfer portion of the 
cache. Again, the invention is supported by including a 
test for the Cache Protection Violation following state (c) . 
The KHU Protection Violation test on the translated address 
is similarly performed in state (g) . 

The write back state machine shown in Figure 7 defines 
the control of the Write Back bus cycle to memory. This 
cycle may be performed in parallel with CPU cache accesses, 
since both the Write BacX controls and data path are 
independent of the cache access controls and data path. As 
described below, the "Memory Busy" signal causes the address 
and data state machines to wait until a previous Write Back 
cycle has completed. 

The write cache miss timing diagram shown in Figure 8 
defines the overall timing of a CPU write bus cycle to 
memory which misses the cache. The cache Hit and 
Protection Check occur in cycle (c) in this diagram. 

A part of the miss handling setjuence includes the 
leading of the current cache block which is being replaced 
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into write back buffer 39 in cycles (i) and (m) . The 
translated address for the current cache block is also 
loaded into real address register 51 in cycle (o) . If the 
current cache block is both Valid and Modified fro* a 
previous CPU (or DVKA) write cycle, then this cache block 
will be writtten back to memory 31 through a Write Back bus 
cycle, described in both the Memory Data Bus timing and the 
Write Back state machine, Figures 10 and 7 respectively. 

The CPU write data is merged with block data 
returned from memory on the first data transfer of a 
Block Read memory bus cycle. During cycles (q) through 
(u) , the CPU Write Output Enable controlling buffers 37 
will be active for only those bytes to be written by 
the CPU, while the Data Register Output Enable 
controlling data register 61 will be active for all 
other bytes. During the second data transfer, cycle 
(w) , the Data Register Output Enables for all bytes 
will be active. 

The read cache miss timing diagram shown in Figure 9 
defines the overall timing of a CPU read bus cycle to a 
cacheable page in memory which misses the cache. The cache 
Hit and Protection Check occur in cycle (c) in this 
diagram. 

X part of the miss handling sequence includes the 
loading of the current cache block which is being replaced 



into write back buffer 39 in cycles (i) and (») . The 
translated address for tfce current cache block is also 
loaded into real address, register 51 in cycle (o) . If the 
current cache block is both Valid and Modified from a 
previous CPU (or DVMA) write cycle, then this cache block 
will be writtten back to memory 31 through a Write Back bus 
cycle, described in both the Memory Data Bus Timing and the 
Write Back State Machine, Figures 10a and b and 7 respectively. 

Data is read to the CPU by simultaneously bypassing t*e 
data to the CPU through buffers 37 enabled by control signal 
CPU Read Output Enable, active in states (q) through (u) , 
and updating the cache, in state (s) . The memory is designed 
to always return the "missing data- on the first 64 bit 
transfer, of a Block Read memory bus cycle and the alternate 
64 bits on the subsequent transfer. After the CPU read bus 
cycle data is returned, the CPU may run internal cycles 
while the cache is being updated with the second data 
transfer from memory. 

The Memory Data Bus timing shown in Figure 10a and 10b. 
.hows the timing of Block Read and Write Back bus cycles. 
Since the cache block size is 128 bits, each cache block 
update requires two data transfers. As indicated above the 
64 bits. containing the data addressed by CPU 11 are always 
returned cn the first transfer for Block Read bus cycles. 
The "Memory Busy" control signal active during the Write 
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Back cycle is used to inhibit the start of the next cache 
aias cycle until the previous Write BacX cycle can complete. 

cache flush logic 33 shown in Figure 11 outlines the 
control and data path of the flush controller. This 
controller implements the cache flush operations of the 
present invention for a system with multiple active user 
contexts and a shared operating system. Cache flush logic 
comprises AND gate 48, flip-flops 49, flush address register 
52, incrementer 50, AND gates 55 and OR gate 58. 

Three flush match signals ere used by cache flush logic 
33 to determine whether the addressed cache bloc* is to be 
flushed. Corresponding to the three flush match signals are 
three flush commands issued by the CPU. A Flush Match is 
said to occur if: 

' (Context Flush Command.) AND (Context Flush Match Signal) 
(Segment Flush Command ) AND (Segment Flush Hatch Signal) 
(Page Flush Command) AND (Page Flush Match Signal) . 
An implementation of such flush match logic is shown in 
-Figure 12 comprising comparators 60, AND gate 62, Inverter 
64, OR gate 66 and AND gates 68. 

Flush control logic 33 involves two distinct phases, 
which are shown as separate sequences in the flush state 
machine^ Figure 13. The first phase involves decoding a 
Flush command from the CPU and obtaining bus mastership for 
the Flush Control State Machine. The Flush command is 
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OR 



i.su.d by the CPU in Control Spec. (id.ntlfied by Function 
cod. bits FC ( 2,0>-0*,>. Within control Space, the .our high 
order address bits A(31:2 8 )-0*X indicate the Flush commend. 
Th. address field M27i0) for the command correspond to th. 
28 bit virtual address field for data accesses. The rlush 
command data bits 1.(1:0) encode th. type of flush. After 
the Flush command is d.coded, the address field A<27 = 9 > is 
latched toother with the type of flush. X Bus Keenest 
signal is asserted to the CPU to obtain bus mastership. 

The second phase Involves performing DVKA cycle, to 
test and flush, if necessary. 32 cache bloc*, using cache 
flush logic M a. a DVMA device. This DVKA device addresses 
each, blocks with the virtual address A<27: 9 , captured tro» 
t*. xlush command, plus address bit. A(5:4> an internal 

S bit flush address counter 50. Each cache bloc* may be 
checked in three cycles, vith the three Flush Match signals 
get.d by the Flush contend latches 55 to determine a -Fiush 
Ketch" condition. A "Flush Hatch" results in the cache 
Woo* being Invalidated and a Modified bloc* being written 
to memory through the Vrite Bsc* state machine. Following 
th. conclusion of the 32 bloc* check, bus mastership may be 
returned to the CPU. 

Hot. that as a DVMA device, the caphe flush logic 33 
competes vitb other C v«x devices for bus ownership. Of the 
possible three SVM* devices, Ethernet (not ehown) has the 
highest priority, th. cache flush logic 33 second priority, 
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and VKSbus devices third.* The flush control state machine 
does not include a complete arbitration description for all 
DVHA devices, .but rather only logic related to the Flush. 

The cache flush state machine shown in Figure 13 
comprises four interacting machines vhich control the flush 
operation. These four machines control the decode of the 
CPU Flush command and its application to 32 cache blocks. 
The four machines are described below: 

1) The Command Decode machine decodes the Flush command 
executed by the CPU. Upon decoding a Flush command, 
the flusb virtual address A(27:9) and the type of Flush 
command are latched. The machine asserts a Bus Request 
to the CPU to obtain bus mastership for the flush state 
machine. It also asserts a Flush Request signal to 
activate the DVHA machine, below. 

2) The DVHA machine obtains bus mastership from the 
CPU, as indicated by the CPU's asserting Bus Grant, and 
holds mastership by asserting Bus Grant Acknowledge. 

It arbitrates the Flush with the higher priority 
Ethernet requests. 

3) The Flush Compare machine initializes its address 
counter A(8:4> to 0 with the Flush Request signal. It 
continues to check cache blocks as long as Flush Co is 
asserted by the DVHA machine. When Flush Go ie 
deasserted, a Flush Done signal is set at the 
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conclusion of the current bloc* flush, which signals 
the DVMA machine to grant mastership to the Ethernet 
handler. If a Flush Hatch is detected, the Flush Block 
Request signal is asserted to activate the Flush Match 
machine. At the conclusion of the Flush Match machine, 
this machine returns a Write Back Request signal to 
' complete the machine's handling of the current cache 
block. 

4) The Flush Match machine loads the cache data into 
write back buffer 39, clocks the translated cache 
address in real address register. 51, and invalidates 
the cache tags 33. Note that no protection check is 
performed. At the conclusion, the Write Back Request 
signal is asserted. If the cache block is marked as 
Modified, the Start Write Back Cycle signal is also 
asserted to activate the write back state machine shown 
in Figure 7. 

Figure 14 shows cache flush timing and describes the 
timing of a block flush in the event of a "Flush Match". 
This condition is tested in state (c) . The block is 
invalidated in state (k) . If the block satisf ies the "Flush 
Match" and is Modified, then it must be written back to 
memory. A -Start Write Back Cycle" signal is asserted in 
state (b) to begin the Write Back state machine. 
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The kernel changes needed to support the virtual 
address write back cache of the present invention for the 
Unix operating system are shouin in Appendix A. 
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K.».l t^.ign D oc»«t for Vi^ *ddr«. C.ch. 

3. An Invariant Condition - t _ virtual Addrsis Cache <c*H«d 

tlMI. 

If an entry is In the cache, it. mapping from virtual 
JddSss tophysical addreae n»t be correct. 

Thi. i. » .utficicnt condition for the correctness of the ay.tem 
because of the following: _ w-M-./word from the 

J£ile the capping i. ""• ct ^"^%jJS;,iSl m££rytbrough MMU 

napping becomes incorrect. 

21. Cache Flushing Strategies tlloe . eoniUjn ing, „• avoid cache 

— slnc » c * ch t flu,hin * I SnII/Soo machine, i pigi fl»»h takes 

.... 

if they%re accessed one at a tine, *• consider the 

3.) Ke ignore 5*^*~!~ A . not -vaianteed to be consistent 
a) access °f j£ e *'~Mt th^viitull address cache, 2) auch 
even -pn system* rith « t "*"",;j e " u „ BO , t of auch usages 
.dded of SSSSiiig processes and these » page. 

turn off the cache of do%#n th* entire system 

This means any user process can slow own v«« 
considerably l>y open /dev/»m. 

^ ^xh^ffllo^routine. are added to th. kernel: 



1) vacjotxf lush 0 fluehes the cache by Context -match, Zt flushes 
all caehe lines whoee supervisor bits In the caehe tag are off Am whose 
context id's in each* tags match that of the KHU con tart register. 

Z.e. it flushes an antira user context, .vacje^xflush () ia defined In 
aoap.s. • — . ^ 

2) vac_eegf lush (segment_number) flush as the eaeha by segment-mateh. 
3t flushes all cadhe lines whose segment address parts <A<16-27> in BUN-3) 
of the eaeha tag match •segment jnumber" either from a kernel tddress 
apaee or from the current user's address space. I.e. it flushes either 

a kernel segment or a user segment of the current user context. 
▼ae_segflush() is defined In map. a. 

3) wae_pageflush(virtusl address) flushes the cache by page-match. 
It flushss all cache lines whose page address parts <A<13-27> in SUN -3) 

of the cache tag Batch the page number part of •virtual address" either 
from a kernel address space or from the current user's address space. 
I.e. it flushss either a kernel page or a ussr page of the current user 
context. vacjpageflushO i» defined in map. a. 

4) vae_f lush (virtual address, nusxsber of bytes) flushae the cache 
llnea whose page address parts (A<13-27> in SUN~3) of the cache tsgs are in 
the ranges of ["vlrtualjeddress", "virtual address" + ■ number of bytea" - 1] ♦ 
It flushes these lines either from a kerneT address space or 7rom the 
current user's address space. vac_flush() is used either to flush less 
than a page, such as from resume ()7 or to flush a number of contiguous 
pages, such as from pageout<). vae_flush() is defined in aap.s. 

5) vac fluahalK) flushes the entire eaeha. Zt is used to flush 
the entire cache to the physical memory before we dump the physical 
memory from dumps ys () . It may also be used as an debugging tool, 
vacjf lushall <) is defined in vm_machdep.e. 

€) vae_disable_kpage (vlrtual_address) turns off the caching of 
a kernel page starting at "virtual address"? Zt is used by the device 
driver mmap{) routine to enforce tTTe consistency of sharing a kernel page 
with user pages. vacjdieable_kpage () le defined in vm_machdep.c. 

7) vac_enable_kpage (virtual address) turns on the caching of a 
kernel page atarting at "vlrtual_address". If a device driver snap 
routine knows that no more user pages are aharing a kernel page, it 
calls vac_enable_kpage() to allow the caching of this kernel page, 
vacjenable^kpage () is dsfined in vm_machdsp.c 

TV . Where and how do we flush the cache ? 

1) We call vac_ctxflush(> from ctxfreeO in vmjnaehdep.c. 
{ CtxfreeO is called whan a context is freed from HMD 
and hence the mapping of the whole context is not valid. 
CtxfreeO is called from ctxallocO whan the oldest 
context is bumped out of KMU, from swap out () whan a 
process is swapped out, from exit() when a process 

is terminated, and from ptexpand () when this context 
is given up before its pte's are expanded. ) 

2) We eall vac_etxf lush (> from vralvm() in vmorec.e. 

{ VrelvmO releases the vm resources associated with thia 
process. This will cause all virtual and physical psgas of 
the process be released and thus invalidate- all virtual to 
physical mappings of the current context. ) 

3) We eall vae_ctxf luah () from expand {) in vm_proe.c* 

( This happens when a process is shrinking and it gives back 
eome virtual memory. ) 

4) We eall vac__ctxf lush () from ©vadvieeO in kern_mman.c» 

{ Whan the parameter to vadvieeO ia VX_TLUSH,"we Invalidate 
all page table entriee of the current p?ocees, A context flush 
is more efficient than a number of page flushss. ) 

5) We call vac_eegfluah () from pmegrelease () in vm_machdep.c 
f Fmeereleate () ia called when a pmeq is taken awav. 
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FmegreleaseO can be called by either poegalloc() or 
pmegallocres () . } 
€) We call vae eegflusM) from poiegload () in vm_machdep.c. 
( A segment~in the hole is to be freed and eet to SEGINV 
in the segment map. ) 

7) We call vac page flush {) from pageout {) in vmpage.c. 

{ This is wKen a page is narked invalid by tne pageout 
demon. ) m 

8) We call vac page flush () from ovadviseO in kern_nman.e. 
< This is wKen ovadviseO narks a page invalid. > 

9) We call vac page flush () from mapout () of vmjaachdep . c . 
{ Mapout () Is called to release a mapping from kernel 
virtual address to physical address. 

Mapout <) is called from: m a , 

a) physstrat () when mapping from kernel virtual address to 

user buffer address is released. * 
1}) wmemfreeO 

c) cleanup () 

d) ptexpandO to release old page tables. > 

10) We call vac pagef lush () from pagemove () of vmjaachdep . c . 

{ In pagemove () we call vacj>agef lush (to) because the mapping 
of "to* to its physical page is .not valid after aetpgmapO call, 
We call vac_pagef lush (from) because the mapping of "from" 
to the physical page is not valid after the second 
aetpgmapO call. ) 

11) We call vac pagef lush () from nbrelse () of sundev/nb.c. 

{ This is when setpgmap (addr, 0) is called to invalidate 
the mapping from DVMA virtual addresses to physical 
addresses. ) 

12) We call vac flush () from resume () in vax.s. 

{ At the end""of context switch time, the mapping of the 
outgoing process's u becomes invalid. We should flush 
the outgoing process's u before its u mapping becomes invalid. 
Since context switch happens very frequent, we only flushes 
the user struct and the kernel stack , instead of flushing 
the entire u page. (Resume () is also called from procdupO 
to force an update of u.) } 

13) We call vae_fluah() from snmapO, munmapO, and munmapfdO 
in kern ismanTc. 

{ Virtual to physical mappings of some pages are changed. ) 

14) We call vac flushallO from duxnpsysO of machdep.c to 
flush out the content of the entire vac to physical memory 
in order to dunp out the physical memory. 

15) There are a number of places where virtual-to-phyaical 
mappings are invalidated illicitly, e.g. the pme/pte mapping 
ia still valid but this mapping is never used again. We 
must flush the associated portion of cache, otherwise, when 

a new mapping is set up from this virtual address, the 
cache may contain some lines of the previous mapping. 

a) We call vac_pegef lush () from nbsetupO of sundev/mb.c. 
{ In mbeetupO, the mapping from pte's to physical 
pages is temporarily (until mbrelase) replaced by the 
mapping from DVMA virtual addresses. ) 

b) We cell vac pagef lush () from dump eye () of machdep.c. 

* I The last page in the DVMA region is used to map to one 
physical page at a time to durrp out the physical memory. 
Such a mapping is invalid each time after (*dumper) {) 

is called. ) . . 

c) We call vac pagef lush () from physstrat () of machdep.c. 
i In physstrat (), "user* pages are doubly mapped to 
the kernel space. We flush these user pages when we set 

up the associated kernel pages. Xater, these mappings from 
kernel virtual pages to physical pages are invalidated by 
mapout (), there these kernel virtual addresses are 
flushed. ) 

d) We call vac paqefluahO from copvseaO of machdep.c. 



( Xn copysegO* fcl'ie -capping 2sozx address CADDR1 

to physical address *pgno" becotnes invalid after copylnO* 

m) We call vacpagef lush () from onrw() of sun3/mam.c. 

{ Xn nnrv(), the napping from •vnmap" to a physical address 

is set up to eopy physical data to the user apace. This 

sapping becomes invalid after uioaoyeO* ) 
£) ITe call vac_pagef lush {) f rom pagein () In vmjage.c. 

{ The napping from CXDDR1 to physical page pf+1 beoooee 

invalid after bzeroO* ) 

g) Ke call vac flush () from procdupO of vm_proc.c 

to flush the kernel stack and u_* parts of forkutl. 

{ Xn' procdupO , forkutl maps to~the physical u page 

of the child process through vgetuO. 

Since the mapping from forkutl to the physical u page 

of the child becomes invalid when the parent returns from 

procdupO, forkutl la flushed before procdupO returns. 

h) He call vac_flushO from newproeO of kernjfork.c 
to flush the u_* part of vfutl. 

{ Xn newproeO* In the case of.vfork, vfutl saps to 
the physical page of the child through uaccessO* 
This mapping Is not used anymore after vpassvm() 
is called. } 

1) Ke call vae_f lush () from swspout <) of vxn_ewap.o 
to flush the u * part of utl. 

{ Xn awapoutOT mapping from utl, which is either 
xswaputl or xswap2utl # to the physical u page of proc p 
is Invalid after proc p is swapped out. } 
3) We call vac flush () from swapinO of vm_swap.c 
to flush the u_* part of utl. 

{ Xn swapinOr mapping from swaputl to the physical 
u page of proc p becomes invalid before we return from 
swapinO. ) 

k) We call vac_pagef lush 0 from swapO of vre_aup.e. 

{ The mapping from i-th virtual page of process 2 to 

the physical page is not valid anymore. ) 
1) We call vac_flushO from pageout O of vxnjage.c 

to flush the u_* part of pushutl. 

{ Xn pageout o7 the mapping from pushutl to the physical 
u page of rp become invalid after the vtod() call. ) 

m) We call vac flush () from pageout () of vmjpage.c to 
flush the cTuster of pages to be paged out. 
{ SwapO maps the physical pages of these pages to virtual 
addresses of proc [2] before it calls physstrat(). Thus, 
the mappings from the outgoing virtual pages to physical 
pages are to be replaced by those of proc [2] virtual pages 
to these physical pages. Therefore, we flush these pages 
in page oat () before swapO is called. ) 

n) We call vecpegef lush O from kmcopyO of vm_pt.c. 
{ kmcopyO la called from pt expand () to •copy" pte's 
from old pte'a to new pte'a. It •copies* by mapinO 
new pte'a to the physical pages of old pte f s. We flush 
old pte'a before new pte'.s are mapped-in. ) 

o) Ke call vac_pagef lush () from distpteO of vm_pt.c. 

{ distpteO is called when the pte entries of a shared 
text pte is changed. For example, pageout () changes its 
valid bit to invalid. Since other processes sharing this 
text page may have this text page in the cache, we flush 
out this page for all aharing processes. } 

p) We call vac flush () from vrelptO of vmj>t.c to flush 
the pte's o? the outgoing process. 

{ Xn vrelptO* the pages that contains pte's are released 
but mapout () is not called. > 
q) We call vac_pagef lush () from wlokjunlock of 
aunwlndowdev/winlock. c. 
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{ Xn wlok unlock O, snppiaq f,sem wloc:'.->l©k_ueer 

to the phyeioal « pay* o rvxu'..Z '..tomii bocomee 
Invalid If wleck-> lok user is nonzero. ) 
r) Wo call vecj>agef lush (7 from wlok_done () of 
sunwindowdev/winlock . ©. " 

{ m wlok doneO, the napping from wlock->lok«eer 
to the physical u page become* invalid. J . 
16) When protection bite are changed and the affected portion 
of the cache should be flushed. Such places are: 

a) In ehgprotO of vm maehdep.c, we change the protection 
of text page*. We~call vacpageflush <) there to avoid 
having any entry in the cache with different protection 

b) X^aettprocO of vm maehdep.c we change the protection 
' bit" efW pages ~ We call v.c_f lush (> to flush 

the text part of the process, (aettprot {) is called 
from vm text.e.) 

c) in vac_dieable kpage <) of ym maehdep.c we call 

vac pagef lush (7 to flush all cache lines of this page 
before asking the page non-cached. 

V. Whv don't we flush the cache here ? 

v. Why. ^g^a-jsj irvint cTplece. where the mapping t ram 
virtual addresses to physical addresses are changed but the cache 
is nSt flushed. We describe the reasons why cache flushings 
are not () of ^ ^.ehdep.c, the virtual to physical 

mapping of pro c p Is changed to that of proc q. But, q 
gets whatever in the cache previous belong to p, ao no 

? e c2«...0 8 ia C S2Je5°Sy P vp»««Pt<) to pass the context of p 

*vp.Lp? ("ii «3.7by vpassvmO which is ore 
«nd after vforkO . vpassvmO passes the ym ^""urces and 
the MMU context of p to q. When vpaa a vm () return. , the 
virtual to physical mapping for the context i» not changed. 
airl* the context is also passed, the affected mappings in 
Se" cacnl trl Hill correct, except that now they b-long^o 
proc J instead of proc p. Therefore, there is no need to 
flush the cache either in etxpassO or in vpassvmO . ) 

2) in vpssspM), the virtual-to-physic.l mappings of processes 
-up- and "uq' are not changed when vpasspt O returns. 

(Or more precisely, the mappings are changes back to 
the eame as the mappings when vpasspt () is entered). 

3) Xn ewlVo of vm swpTc, if -flag- indicates a dirty page 
SshT the mapping of addr to physical address is replaced 
by that of th? i-th page of proc[2J. Since dirty pages 
have been flushed in pageoutO, there is no need to flush 
-addr" again in swapO . ,. 

4) In pmegloadO of vm maehdep.c, when *pmxp (ctx pmeglseg ) 
' I. ITrl and Ineed, we invalidate pmegleeg]. since we did 

either a context flush (in ctxf ree () ) or a segment flush 
tin pmegrelease ()) when we set ctx pmeglseg] to aero, 
there is no need to do a segment flush here. 

* There are only two places where we set (struct context -)-> 
. it££eg*.eg? to aero! One is in F™*"*"" » " 
vacsegf lush (seg) and setsegmap(seg, SEGINV). rtSf£lu . ntl 
The-other place is in ctxf ree () where we call vac_ctxf lush () 
but don't setsegmap(seg, SEGINV). 

Hence (struct context *) ->ctx_pmeg[seg] f^ 0 *"* ™° 
segmap is not SEGINV in this case. The reMOi^ that 
when •pnxp — 0 and Ineed in pmegloadO needs a 
aeSegmap(.eg, SEGINV) ia to make MKO .egmep to be KGXHV. 
Since Ve have done a vac_ctxf lush () in ctxfree 0 , thia 
segment ahould not have any left-over in «»• /^J? • ' 

5) In ctxallocO of vmjnachdep.c, eetaegmapO is called 
to invalidate all mappings from the aeoment map. Since 



7) 



ctxfreeO la called earlier to ftg the •«tire 

context, no lines associated with these ••9"»nts 

u« m the cache. Therefore, segment flushes are not 

6) xTptJsyncO of vm machdep.c, ptesyncO calls pmegunloadO 
SiS Sfi tht modTbits to pte'e and reset the mod bits of 
int p^5. Shin ™ check ifanother page in this pmeg *• dirty, 

we check its pte which remembers the mod bit was on. 

Se don't need to flush the segment becauae pmegunload turns 
©ff the mod bits in this pmeg. 

unloadpgmapO of map. s saves the referenced and modified 
JStTSomiaiff pme tS soft pte and * h ?" ^ 

£me. Since when we do pageout or swapout, JJ 
Pte that we check to decide if a page is dirty, there is no 
need to flush the cache when the referenced and modified 

B) ^gunloTdtt'of-l-chdep.c, J-jjCgJj 
pmp-pmeg), unloadpgmap( v, pte, num) , and ••£*9^<Cf* 8 ' 
SEGINV) ! In unloadpgmapO, segment map of CSEG is used to 
access the pme's in this segment. Virtual address of 
aeoment CSEG is not accessed, thus segment CSEG doesn't 
havTanyinlng in the c.che. Therefore, there !• " »•« 
to call vaceegf lush (CSEG) before we invalidate this 

9) Jn'mtpoutO of vm_machdep . c, when w* invalidate a fW"*^ 
by calling setsegmap ( (u int) ptds (btop (vaddr) ) , <u_ehar ) SEGXKV) , 
Zl hive dine paglflushes on all previously used pages in this 
augment. Therefore, there is no need to do a segment flush. 
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CLAIMS 

.1. in a workstation utilizing a virtual address write back 
cache including a central processor having an address bus and a 
data bus, a cache data array, having a plurality of cache blocks, 
a cache tag array having an array element for each of said cache 
blocks, each of said array elements having a Valid bit, a Modified 
bit and a Supervisor Protect bit, a vrite back buffer, a memory 
management unit, a main memory, a cache hit detector, a context 
identification register, flush control logic and workstation 
control logic, the improvement wherein said cache hit detector is 
modified to detect cache hits in a shared operating system across 
multiple active user contexts, and wherein said workstation further 
comprises: 

a) means for reassigning virtual addresses across multiple 
user contexts; 

b) means for completing a cache block flush operation before 
control is returned to the central processor upon the issuance of a 
flush command, and in each said flush operation, flushing all cache 
blocks having their associated cache tag array element Valid bit 
set, prior to reassignment of the virtual addresses. 

2. The improvement defined by Claim 1 wherein said modified 
cache hit detector comprises: 

a) means for detecting cache blocks having their corresponding 
cache tag array element Valid bit set; ' 



b) first means for determining whether for the cache block 
being addressed by the central processor, said cache block address 
having a plurality of access virtual address bits, said access 
virtual address bits match virtual address field bits in a 
corresponding dache tag array element; 

c) second means for determining whether i) for the cache block 
being addressed by the central processor, said said cache block 
address having a plurality of access context bits, said access 
context bits match context bits in the corresponding cache tag 
array element; and ii) the Supervisor Protect bit is set in the 
corresponding cache tag array element. 

3 # The improvement defined by Claim 1 wherein said 
reassigning means comprises: 

a set of flush commands disposed within the shared operating 
system, said flush commands being a context match flush command, a 
page match flush command, and a segment match flush command - 

4. The improvement defined by Claim 1 wherein said flush 
operation completing means comprises: 

a) means for decoding said flush command, said flush command 
being one of a context match flush command, page match flush 
command and segment match flush command; 

b) flush address register means for storing an address 
included in said decoded flush command; 



c) incrementing means for incrementing predetermined address 
bits for combining with the address bits in said flush address 
register means; 

d) flush match means coupled to said decoding means for 
generating a flush match logic signal, 

vhereby the issuance of a flush command causes all cache 
blocks having their associated Valid bit «et to be flushed prior to 
reassignment of the virtual addresses. 

5- The improvement defined by Claim 2 wherein said detecting 
means comprises a first AND gate having a first input coupled to 
the Valid bit of the array element in the cache tag array 
corresponding to the cache block being addressed by the central 
processor. 

'E. The improvement defined by Claim 5 wherein said first 
determining means comprises a first comparator coupled to said 
address bus and said cache tag array, the output of said first 
comparator coupled to a second input of said first AND gate, 

7. The improvement defined by Claim 6 wherein said second 
determining means comprises a second comparator coupled to said 
context identification register and said cache tag array, the 
output of said second comparator coupled to a first input of an XOR 
gate, a second input of said XOR gate coupled to the Supervisor 
Protect bit in the cache tag array element corresponding to the 
cache block addressed by the central processor-. 



fl . The improvement defined by Claim 7 vherein said modified 
cache hit detector further comprises: 

a) a second AND gate having one input coupled to the output of 
.aid XOR gate, » second input coupled to the output of said first 
AND gate and a third input coupled to the output of a third 
comparator whose inputs are coupled to said address bus and the 
array element of said cache tag array addressed by said central 
processor; 

b) a fourth comparator whose inputs are coupled to said 
address bus and the array element of said cache tag array addressed 
by said central processor, the output of said fourth comparator 
being a third input of said first AND gate. 

9 . The improvement defined by Claim h wherein said 

decoding means comprises an AND gate coupled to said central 
processor and first, second and third flip-flops having their cloc* 
inputs coupled to the output of said AND gate and their D-inputs 
coupled to said data bus. 

1Q. The improvement defined by Claim ? wherein said 

flush address register means comprises a register which loads 
predetermined bits from the address bus when the output of said AND 
gate is set. 

11. The improvement defined by Claim 9 vherein said 
flush match means comprises first, second and third AND gates, each 
having one input coupled to the Q outputs of said first, second and 
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ror generating a segment match signal, a page match signal and n 
context match signal, an OK gate having first, second and third 
inputs coupled respectively to the outputs of said first, second 
and third AND gates, vhereby the output of said OR gate is set when 
ona of said segment, page and context match signals are set and a 
corresponding segment, page and segment command has been decoded. 

12. A workstation substantially as herein described with reference to 
end as illustrated in the accompanying drawings. 





